home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-06 / an008b.zip / AN008B.TXT < prev   
Text File  |  1991-01-29  |  26KB  |  525 lines

  1. A Comparison of NetWare IPX, SPX and NetBIOS 
  2.  
  3.  Bill Bodine
  4.  Consultant
  5.  Systems Engineering Division
  6.  
  7. Abstract:
  8.  
  9. One of the first questions always asked during comparisons of NetWare 
  10. IPX, SPX and NetBIOS is which of these protocols will transfer data 
  11. the fastest, and how much slower the others are. This AppNote details 
  12. the results of four benchmarks written to illustrate the relative 
  13. speed of each of these communication interfaces. Performance, maximum 
  14. packet length, naming capabilities and memory usage are each singled 
  15. out as additional factors in the decision to implement systems using 
  16. these protocols. Clarification and explanation of SHELL.CFG parameters 
  17. are also included.
  18.  
  19. Novell, Inc. makes no representations or warranties with respect to 
  20. the contents or use of these Application Notes, or any of the third-party 
  21. products discussed in the AppNotes. Novell reserves the right to revise 
  22. these Application Notes and to make changes in their contents at any 
  23. time, without obligation to notify any person or entity of such revisions 
  24. or changes. These AppNotes do not constitute an endorsement of the 
  25. third-party product or products that were tested. The configuration 
  26. or configurations tested or described may or may not be the only available 
  27. solution. Any test is not a determination of product quality or
  28. correctness, nor does it ensure compliance with any federal, state or local
  29. requirements. Novell does not warranty products except as stated in
  30. applicable Novell product warranties or license agreements.
  31.  
  32. Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved.
  33.  
  34. As a means of promoting NetWare Application Notes, Novell grants you 
  35. without charge the right to reproduce, distribute and use copies of 
  36. the AppNotes provided you do not receive any payment, commercial benefit 
  37. or other consideration for the reproduction or distribution, or change 
  38. any copyright notices appearing on or in the document.
  39.  
  40. Introduction
  41.  
  42. When Novell began operations in 1982, several proprietary protocols 
  43. for transferring data between workstations were used. As time went 
  44. on, the decision was made to base Novell's network communications 
  45. on a fast and efficient networking standard. Xerox's XNS protocol 
  46. was determined to be one of the best available at the time so Novell's 
  47. Internetwork Packet Exchange (IPX) protocol was developed to conform 
  48. to the XNS standard. NetWare IPX is functionally equivalent to Xerox's 
  49. Internet Datagram Protocol (IDP). 
  50.  
  51. This AppNote discusses the three primary peer-to-peer protocols 
  52. that are supported in the NetWare LAN environment-NetWare IPX, SPX 
  53. and NetBIOS. Additional protocols supported include the Transport 
  54. Layer Interface (TLI), Named Pipes, LU6.2 and others, but are not 
  55. covered in this AppNote.
  56.  
  57. NetWare IPX
  58.  
  59. NetWare IPX is a true datagram protocol. It makes a best-effort 
  60. attempt to send packets by using a 12-byte addressing scheme. 
  61. The 12-byte address is split into three addresses: the network 
  62. address, which is used to address individual workgroups; the node 
  63. address, which addresses network nodes within the workgroups; and 
  64. the socket address, which can be used to multiplex between functions 
  65. within a network node. When sending an NetWare IPX packet from one 
  66. node to another, the sending node must know the receiving node's 12-byte 
  67. address. 
  68.  
  69. SPX
  70.  
  71. The Sequenced Packet Exchange protocol (SPX) is a connection-oriented 
  72. communications protocol that is built upon NetWare IPX. When a call 
  73. is made to SPX to send a packet by an application program, SPX will 
  74. do some housekeeping-type work on the packet, but will call NetWare 
  75. IPX to actually send the packet. SPX guarantees packet delivery, whereas 
  76. NetWare IPX only gives a best effort to deliver packets. This added 
  77. feature of SPX has obvious advantages, but as we shall see later in 
  78. the paper, it also adds overhead to the data transfer cycle and is 
  79. slower. 
  80.  
  81. NetBIOS
  82.  
  83. The Network Basic Input/Output System (NetBIOS) functions in either 
  84. a connectionless mode or a connection-oriented mode. An application 
  85. written to the NetBIOS interface can be designed to use either of 
  86. these modes. For instance, if an application functions in a request/reply 
  87. mode with a transfer size of only one packet, then the connectionless 
  88. mode should be used to take advantage of connectionless response times. 
  89. On the other hand, if most of the transfers are one-sided or consist 
  90. of large numbers of packets, the transfers should use the connection-
  91. oriented mode in order to ensure packet delivery and integrity of data. 
  92. Novell's NetBIOS emulator is built upon NetWare IPX in the same way 
  93. that SPX is.
  94.  
  95. The NetBIOS emulator is called an emulator because it is implemented 
  96. entirely in software, whereas the original NetBIOS introduced by IBM 
  97. and Sytek was located in firmware. 
  98.  
  99. Because NetBIOS was introduced by IBM, it was almost instantly accepted 
  100. as an industry standard. Most networking vendors have implemented 
  101. the specification given by IBM that allows almost any application 
  102. written to the NetBIOS interface to operate in any environment. 
  103.  
  104. A common problem with the NetBIOS specification, however, is that 
  105. it only deals with the upper layer functions of the interface. It 
  106. does not specify what communications protocol should be used underneath 
  107. it. As a result, almost every networking vendor has written NetBIOS 
  108. on top of their own proprietary communications protocol, which cannot 
  109. communicate with other vendors' protocols. 
  110.  
  111. A nice feature that NetBIOS has to offer the networking industry is 
  112. its allowance of easy address resolution among locally-connected 
  113. workstations. All nodes on a network that use NetBIOS register a unique 
  114. name. When a node desires to communicate with another node, all it 
  115. needs to know is the node's unique NetBIOS name and NetBIOS will ensure 
  116. that the packet arrives at the proper location. 
  117.  
  118. Performance Results
  119.  
  120. One of the first questions regarding the comparison of NetWare IPX, 
  121. SPX and NetBIOS is which of these protocols will transfer data the 
  122. fastest, and how much slower the others are. As part of this AppNote, 
  123. four benchmarks have been written to illustrate the relative speed 
  124. of each of these communications interfaces. The scope of the benchmark 
  125. is relatively simple-to send 2,000 255-byte packets and to record 
  126. the time that it takes for the transfer to complete. All the programs 
  127. were written by the same person and were intentionally kept as simple 
  128. as possible to make each benchmark represent the speed of the interface 
  129. and not efficiencies or lack thereof in the benchmark tests. 
  130.  
  131. Each of the benchmarks encompassed two programs. One program 
  132. was used to send packets and the other was used to receive. The sending 
  133. side sent a packet and then incremented a counter. Before the packet 
  134. was sent, a call was made by the sender to the system clock. Once 
  135. the 2,000th packet had been sent successfully, another call was made 
  136. to the system clock. The first value was subtracted from the second 
  137. and the result represented the time in clock ticks that it took to 
  138. send 2,000 packets on the given communication interface. The receiving 
  139. side did nothing but receive packets and count the number that arrived. 
  140. No other processing took place within the code.
  141.  
  142. The following results were achieved on standard 8MHz 80286-based 
  143. machines on a 4MB Token-Ring network. While the test does not 
  144. represent any real-world scenario, it does indicate the relative 
  145. speed of each interface tested. 
  146.  
  147.      NetWare IPX              366.0 packets per second 
  148.  
  149.      SPX                      140.3 packets per second
  150.  
  151.      Novell NetBIOS datagram  224.8 packets per second
  152.  
  153.      Novell NetBIOS session   135.9 packets per second
  154.  
  155. NetWare IPX is the fastest protocol available from Novell. This is 
  156. expected since all others are written in terms of NetWare IPX. SPX 
  157. and NetBIOS are slower than NetWare IPX due to the extra overhead 
  158. they introduce into the communications process. SPX and the NetBIOS 
  159. session level interface run at virtually the same speed. They both 
  160. have to maintain the same level of connection overhead for the 
  161. guaranteeing of packets and are both written in terms of another 
  162. interface. 
  163.  
  164. Other Decision Criteria
  165.  
  166. There are a few primary differences between writing an application 
  167. to NetWare IPX or SPX and writing an application to NetBIOS. Two of 
  168. these differences deal with the maximum length of packets that can 
  169. be sent and the address resolution. 
  170.  
  171. Maximum Packet Length
  172.  
  173. With NetWare IPX and SPX the maximum packet size that can be sent 
  174. by an application depends on either of two things. If the packet to 
  175. be sent must cross a NetWare bridge, the maximum packet size possible 
  176. is 576 bytes. The bridge will drop any packets that exceed this size. 
  177.  
  178. On the other hand, if the packet will not be crossing any bridges, 
  179. the network interface card (NIC) drivers limit the size. While most 
  180. drivers allow packets of 1,024 bytes or larger to be transferred, 
  181. NetWare documentation recommends that the maximum size transferred 
  182. be 576 bytes. This is in case the packet crosses a bridge or the driver 
  183. cannot handle larger packets. 
  184.  
  185. NetBIOS allows an application to send packets up to 64KB in size. 
  186. This is possible because the NetBIOS emulator breaks the packet into 
  187. smaller packets for the application and sends them out in sizes that 
  188. can be handled by NetWare IPX and the NIC drivers. While this feature 
  189. is useful, some developers choose to split packets up themselves in 
  190. order to optimize the NetWare IPX bandwidth for their application. 
  191. This may or may not be a factor in different situations. 
  192.  
  193. Naming Capabilities
  194.  
  195. The second primary difference is the naming capability supplied with 
  196. NetBIOS. NetBIOS makes it convenient for an application to determine 
  197. the addresses of other nodes on the network. Each workstation identifies 
  198. itself with a particular name. Once any other workstation on the LAN 
  199. knows that name, data can be sent between the two workstations. 
  200.  
  201. Novell recognized the need for this easy address resolution when it 
  202. developed NetWare IPX, so the Service Advertising Protocol (SAP) was 
  203. developed. With SAP, a node advertises, or broadcasts to the entire 
  204. network its name and address. This name and address are stored internally 
  205. on all NetWare network file servers. When any other node wants to 
  206. find an address, it queries a NetWare file server and the necessary 
  207. information is returned. There are also other ways of finding an address 
  208. without accessing the NetWare file server, but they are not as common. 
  209.  
  210. Both of these methods have advantages and disadvantages. While it 
  211. is probably easier for an application with the naming capability of 
  212. NetBIOS to be developed, using the SAP provided by NetWare does not 
  213. require much more work. The advantage gained by using the SAP is that 
  214. once the address is resolved, the underlying protocol is very fast. 
  215. The SAP is designed for a client-server environment, which means 
  216. that a client always initiates a dialogue with the server. The client 
  217. can always find the server's address through the SAP. Since all packets 
  218. on the network contain the 12-byte address of the node they were 
  219. sent from, the server will know which address to send responses to.
  220.  
  221. Memory Usage
  222.  
  223. When an application runs on a network workstation, particularly in 
  224. the DOS environment, the amount of memory that is free for the application 
  225. to use is often a primary concern. In NetWare the first software to 
  226. load on the network is a terminate-and-stay-resident (TSR) 
  227. program called IPX.COM. This program contains all the interfaces needed 
  228. to run NetWare IPX programs and SPX, and uses about 14KB of workstation 
  229. memory. This is the only piece of NetWare software that needs to be 
  230. run in the workstation if no communications are needed with any file 
  231. servers. If a file server is needed, the TSR NET3.COM is loaded after 
  232. IPX.COM. This program contains all the functions needed by the workstation 
  233. to communicate with any NetWare file server on the LAN. It uses about 
  234. 38KB of workstation memory. NetBIOS is an optional TSR like NET3.  
  235. IPX.COM must be loaded first. When NetBIOS is loaded it takes up about 
  236. 30KB of workstation memory. Just as NET3 is only used when communications 
  237. are sent to a NetWare file server, NetBIOS is only run if an application 
  238. needs to use the NetBIOS services. Native NetWare does not use NetBIOS 
  239. for any of its communications services.
  240.  
  241. Appendix A lists parameters that have been modified in the recent 
  242. versions of NetBIOS. Because of the differences among versions, they 
  243. will be discussed as they relate to the specific versions. 
  244.  
  245. The values listed in Appendix A are approximates. It is not possible 
  246. to state exactly how much memory any of the three protocols will use 
  247. up because they all contain custom parameters that change their sizes 
  248. and configurations. The parameters that alter these configurations 
  249. are located in a file named SHELL.CFG. As IPX.COM or NetBIOS.EXE is 
  250. loaded, it looks for this file in the local directory or a search 
  251. directory. Once it locates SHELL.CFG it searches within the file to 
  252. determine if any of its default parameters have been altered. These 
  253. parameters can be configured from within the SHELL.CFG file. Appendix 
  254. B of the NetWare Supervisor Reference manual also explains 
  255. the parameters.
  256.  
  257. Conclusion
  258.  
  259. While the primary advantage of writing to NetWare IPX is speed, the 
  260. main advantage of writing to NetBIOS is that the application will 
  261. work on other environments in addition to NetWare. This should obviously 
  262. be considered for applications that are marketed on a variety of platforms.
  263.  
  264. Even though different vendors' NetBIOSs can rarely communicate with 
  265. each other, most applications do port well over these vendors'
  266. implementations.
  267.  
  268. There are a variety of reasons applications are developed to 
  269. one protocol or another. One reason a protocol is chosen is because 
  270. it is perceived as the defacto standard. For many developers, NetBIOS 
  271. is seen as a standard. Applications are developed to that platform 
  272. for reasons of portability to a variety of environments. On the other 
  273. hand, many developers are developing to NetWare IPX because they recognize 
  274. NetWare's large market share and want to reach the greatest market 
  275. possible with the most efficient protocol available.      
  276.  
  277. Sometimes, one protocol may be perceived as easier to develop to than 
  278. another. Of course whether one is actually easier than another depends 
  279. entirely on the resources that are available, such as the Novell C 
  280. Interface libraries for NetWare IPX and SPX, the experience of the 
  281. development team or even available documentation and training.
  282.  
  283. Appendix A: SHELL.CFG Parameters
  284.  
  285. Version 2.0a
  286.  
  287. NetWare IPX Sockets
  288.  
  289. Sockets are typically used by NetWare IPX to determine which process 
  290. within a given node is to receive a packet. For any process to receive 
  291. an NetWare IPX packet, it must first open a socket and then "post" 
  292. a listen on that socket. When NetWare IPX receives a packet, it checks 
  293. the destination socket number and delivers the packet to the process 
  294. that is listening on that socket. The default number of sockets that 
  295. can be opened in one workstation is 20. This can be altered to include 
  296. any value from 10 to 150. NET3 uses up a few NetWare IPX sockets when 
  297. it is loaded, but even with those included, rarely than more than 
  298. 20 sockets will be needed at one time. 
  299.  
  300. NetWare IPX Retry Count
  301.  
  302. This parameter deals with SPX, NET3 and NetBIOS. When any one of these 
  303. modules fails to transfer an NetWare IPX packet, the transfer is
  304. automatically repeated. The number of times it retries is based on the
  305. value set in this parameter. The default is 20, but the value can be set
  306. from 0 to 255. Obviously, either of these extremes is not advisable. If 
  307. the value is too low, connections will constantly timeout. If the 
  308. value is too high, workstations will take a long time detecting broken 
  309. connections. 
  310.  
  311. SPX Connections
  312.  
  313. This option controls the maximum number of SPX connections that can 
  314. be used at any given time. The default value is 15, while the minimums 
  315. and maximums are 5 and 150 respectively. In a client-server type 
  316. environment the default will be sufficient for the client side, but 
  317. the server side may require the maximum to be increased, depending 
  318. on how many clients exist at any one time. Before this value is 
  319. arbitrarily raised it should be recognized that by increasing the 
  320. number of SPX connections in the SHELL.CFG file, IPX.COM will use up 
  321. more of the workstation memory. For each SPX connection that is 
  322. configured SPX will use 54 bytes of RAM. 
  323.  
  324. SPX Listen Timeout
  325.  
  326. SPX uses what are called watchdog packets to ensure that sessions 
  327. between workstations remain active when no other activity is occurring 
  328. on the session. SPX listen timeout, along with the following two
  329. parameters, is used to signal to SPX when a watchdog packet should be 
  330. sent or when one should have been received from the other workstation. 
  331. If SPX has not heard from the workstation on the other side within the 
  332. time specified by SPX listen timeout, it will send a watchdog packet 
  333. asking the other side to respond. The time is indicated in clock ticks. 
  334. The default is 108 ticks (about 6 seconds). The minimum and maximums 
  335. range from 0 to 64KB, although setting the value greater than SPX 
  336. abort timeout (see next entry) will have no improved affect.
  337.  
  338. SPX Abort Timeout
  339.  
  340. SPX abort timeout controls how long an SPX connection has waited to 
  341. hear from the other side and determines the other side is no longer 
  342. communicating. If it is necessary to have a session timeout faster 
  343. than normal, this option can be modified. The default value is 540 
  344. ticks (about 30 seconds), and the minimum and maximum values are the 
  345. same as in the previous option. 
  346.  
  347. SPX Verify Timeout
  348.  
  349. This option determines how often packets should be sent to the other 
  350. side, to indicate. The default is 54 clock ticks (about 3 seconds), 
  351. and the minimum and maximum values range from 0 to 64KB. 
  352.  
  353. Ipatch
  354.  
  355. This option allows the user to patch any location within the NetWare 
  356. IPX data segment with any value desired.
  357.  
  358. Npatch
  359.  
  360. This option allows the user to patch any location within the NetBIOS 
  361. segment with any value desired.
  362.  
  363. NetBIOS Session
  364.  
  365. This option is used in the same way as the SPX connections option. 
  366. The minimum value that can be set is four and the maximum is 250. 
  367. The emulator uses 88 bytes of RAM for each NetBIOS session configured.
  368.  
  369. NetBIOS Commands
  370.  
  371. When an application makes any request of NetBIOS, a command is issued. 
  372. By default, 12 commands can be outstanding within NetBIOS. In other 
  373. words, if 12 requests have been made to NetBIOS, NetBIOS must respond 
  374. to at least one of the requests before more requests can be made. 
  375. This parameter allows a user to configure the number of outstanding 
  376. commands to any value between 4 and 250. For each NetBIOS command 
  377. that is configured, the emulator will use 64 bytes of workstation 
  378. memory.
  379.  
  380. NetBIOS Send Buffers
  381.  
  382. When an application requests NetBIOS to send a packet, control information 
  383. must be initialized for each packet sent. NetBIOS allocates space 
  384. for as many control buffers as are configured by NetBIOS send buffers. 
  385. NetBIOS is a Stop-and-Wait protocol. This means that if an 
  386. application hands two packets to NetBIOS to send, the second will 
  387. not be sent until the first has successfully arrived at its destination. 
  388. NetBIOS requires some buffering space for this second packet. That 
  389. space is essentially accommodated by this configuration parameter. 
  390. The default value for this option is six. The minimum and maximum 
  391. values are four and 20, respectively. Sixty two bytes of RAM are used 
  392. by the emulator for each send buffer that is configured. 
  393.  
  394. NetBIOS Receive Buffers
  395.  
  396. This option is similar to the previous option, except that it relates 
  397. to the number of receives that can arrive at a workstation. Most
  398. applications have the ability to receive a number of packets at a time. 
  399. For example, five requests may be made to NetBIOS to listen for arriving
  400. packets. As NetBIOS receives packets, it puts the control information
  401. pertaining to those packets in the space allocated by NetBIOS. If a second
  402. packet arrives while NetBIOS is still processing the first packet, there 
  403. must be space to buffer that packet until NetBIOS is able to finish 
  404. processing the first packet. The configurable values are the same 
  405. for this option as for the previous one. Under most circumstances 
  406. the default values should suffice. Under extreme conditions, however, 
  407. they may need to be bumped. If many sessions are sending data to NetBIOS, 
  408. increasing this value may improve throughput. As with the send buffers, 
  409. the emulator uses 62 bytes of RAM for each receive buffer that is 
  410. configured.
  411.  
  412. NetBIOS Listen Timeout
  413.  
  414. This option and the next two function in exactly the same in NetBIOS 
  415. as do the corresponding options in SPX.
  416.  
  417. NetBIOS Abort Timeout
  418.  
  419. See SPX abort timeout. 
  420.  
  421. NetBIOS Verify Timeout
  422.  
  423. See SPX verify timeout. 
  424.  
  425. Version 2.1
  426.  
  427. NetBIOS Retry Delay
  428.  
  429. When an application registers a unique name with NetBIOS, NetBIOS 
  430. broadcasts the name to every other NetBIOS workstation on the network. 
  431. If any other workstation has the name already registered, it sends 
  432. a response packet to the workstation trying to add the name. This 
  433. indicates that the name has already been registered elsewhere. 
  434.  
  435. For this scenario to work properly, the workstation adding the name 
  436. must wait to hear from all others on the network. On large networks 
  437. with many bridges this can take much longer than on small networks. 
  438. This parameter is used in conjunction with the NetWare IPX retry count 
  439. to determine the time the workstation will wait when registering a 
  440. NetBIOS name. The node attempting to register the name sends out as 
  441. many packets as are specified by NetWare IPX retry count. The time 
  442. between each send is given in NetBIOS retry delay. If both of these 
  443. values are decreased, the time it takes to add a name will also be 
  444. decreased. 
  445.  
  446. The options are also used when a node is trying to determine the address 
  447. of another node on the network. The first time a packet is sent to 
  448. another node, NetBIOS sends a broadcast on the network asking for 
  449. the workstation that has the name registered to please send a packet 
  450. indicating its address. Once this packet is received the node knows 
  451. where to send the packet. This process requires the requesting workstation 
  452. to give every node on the LAN the chance to respond. 
  453.  
  454. In addition to the naming functions, this parameter is used for session 
  455. maintenance within NetBIOS. When communicating on a session in NetBIOS 
  456. (or SPX) an acknowledgment (ACK) is sent for every packet that is 
  457. initiated on the session. For example, if station A sends a packet 
  458. to station B, the NetBIOS emulator in station B will send an ACK to 
  459. A. If A never receives the ACK, it will assume the packet was lost 
  460. and will re-send the packet.  NetBIOS retry delay is used to determine 
  461. the time a station will wait for an ACK before it assumes the packet 
  462. was lost. 
  463.  
  464. NetWare IPX retry count is also used to determine how many times 
  465. the station will re-send the packet before determining the transmission 
  466. is hopeless.
  467.  
  468. Version 2.15B
  469.  
  470. NetBIOS Retry Count
  471.  
  472. In this version of the emulator, this parameter replaces NetWare IPX 
  473. retry count for determining how long NetBIOS should wait when adding 
  474. a name or querying the network for the address of a name. It also 
  475. replaces NetWare IPX retry count when determining how many times to 
  476. re-send lost packets before determining that a session is no longer 
  477. functional. 
  478.  
  479. Version 3.01
  480.  
  481. In this version of the emulator, the naming functions and the session 
  482. maintenance functions are separated into four different parameters.
  483.  
  484. NetBIOS Retry Delay
  485.  
  486. This parameter now deals exclusively with session maintenance within 
  487. NetBIOS. 
  488.  
  489. NetBIOS Retry Count
  490.  
  491. This parameter is also used entirely for session maintenance in this 
  492. version of the emulator. 
  493.  
  494. NetBIOS Broadcast Delay
  495.  
  496. This parameter deals entirely with name resolution in NetBIOS.
  497.  
  498. NetBIOS Broadcast Count
  499.  
  500. This parameter also deals exclusively with name resolution. 
  501.  
  502. NetBIOS Internet
  503.  
  504. If NetBIOS will be used over LAN bridges, this value should be set 
  505. to on. This indicates that packets are going to take longer to traverse 
  506. the entire internetwork. In such a case, the values for NetBIOS retry 
  507. count, NetBIOS broadcast count, and NetBIOS broadcast delay are by 
  508. default 20, 4 and 38 respectively. If NetBIOS internet is set to off 
  509. (all communication will be done on one network), the default values 
  510. are 10, 2 and 18. If any of these parameters is set within SHELL.CFG, 
  511. the defaults presented by this parameter will not be used. 
  512.  
  513. As can be seen by the options that can be configured with these protocols, 
  514. there are many timing issues involved with them. Any time a connection 
  515. service is offered, timing becomes a key issue. Timing also plays 
  516. a key role in the naming functionality associated with NetBIOS. It 
  517. is mostly for this reason that NetBIOS is not considered to be a useful 
  518. protocol  for wide area communications. Much of NetBIOS deals with 
  519. waiting for workstation responses. Operation of the NetBIOS protocol 
  520. would be prohibitively slow if it also had to wait for responses from 
  521. networks or nodes connected over slow link lines. It is for this reason 
  522. that Novell says its NetBIOS emulator is not supported over lines 
  523. slower than 1 Mbit/s. 
  524.  
  525.